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(57) Abstract: A system and method for facilitating communication between a plurality of buyers ( 1 0) a plurality of suppliers ( 1 2) is 
provided. The communication system provides for coordinated message and response tracking within an electronic marketplace en- 
vironment. Members of an electronic community, buyers (10) and suppliers (12), may submit information to a central database (16) 
maintained by a service provider (14). Such information may comprise company profile and product information. A marketplace 
administrator may browse the database (16) and assemble a list of suppliers (12) and buyers (10) who will receive an invitation for 
membership in a private or public marketplace. A broadcast message (68) and various response (78) tracking objects are assembled 
into a single marketplace object. The marketplace object serves as a mobile repository for all commercial interaction in furtherance 
of completing a purchase transaction between the buyers (10) and suppliers (12). Suppliers (12) who accept the marketplace mem- 
bership invitation are allowed to attach some or all of their product information to the marketplace object 
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ELECTRONIC COMMERCE COMMUNICATION SYSTEMS 
WITH MULTIPLE USER-DEFINED MARKETPLACES, 
CONTROLLED PRICING, AND AUTOMATED 
PURCHASING CAPABILITIES 

BACKGROUND OF TH E INVENTION 

1. The Field of the Invention 

The present invention relates to systems and methods for broadcasting a message 
to a plurality of receivers and for tracking the responses to the broadcast message. 
Specifically, the present invention relates to systems and methods that can be used to 
create private electronic commerce groups called marketplaces and offer membership to 
these marketplaces to selected buyers and suppliers from a larger public group of general 
subscribers comprising a plurality of buyers and a plurality of suppliers. More 
specifically, suppliers and buyers are selectively presented membership to marketplaces 
created on demand by a marketplace owner or trading partner, thereby providing the 
suppliers and buyers with an outlet for efficient commercial interaction in furtherance of 
completing a purchase transaction. 

2. Thg Prior State pffte Art 

The tasks of large scale purchasers of goods or services have remained relatively 
unchanged over the years. These buyers attempt to procure appropriate goods or services, 
balancing the quality of the goods or services with the price of the goods or services. The 
goal of such buyers has always been to purchase goods or services of an appropriate 
quality for a minimum cost. Suppliers of goods or services, on the other hand, are often 
faced with the task of placing information regarding their goods or services into the hands 
of buyers. Thus, a purchase transaction can, in some sense, be viewed as the culmination 
of an exchange of information between a supplier or vendor and a purchaser or buyer. 

Where a purchaser or buyer procures a number of goods or services, it is not 
uncommon for the buyer to solicit bids from one or more suppliers. In the bid, the 
suppliers provide information desired by the buyer. Often times such a bidding process 
allows a buyer to procure goods or services at a reduced or discounted rate since many 
suppliers are willing to lower the asking price of their goods or services under such 
circumstances. Once a buyer has received the bids from various suppliers, the bids may 
be compared and analyzed and the best "deal" taken. 

The above description highlights the various tasks faced by both the buyers and 
the suppliers in completing a transaction. From the suppliers 1 point of view, a large part 
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of the problem can be viewed as one of information dissemination. Suppliers desire to 
have information regarding their company and/or products and services disseminated to 
as many potential purchasers as possible. To further these goals, companies may spend 
money on advertising, hire a sales force, attend trade shows, mail information, or 
5 otherwise attempt to disseminate appropriate information to potential purchasers. 
Unfortunately, a majority of these efforts are largely unproductive and inefficient as the 
supplier must contact a large general group of potential buyers before finding ones that 
are interested in the supplier's products. Suppliers seeking to participate in electronic 
commerce"are faced with the same tremendous difficulty of finding a compatible group 

10 of electronic buyers that desire to purchase the supplier's product. What is needed is a 
system or method that provides the supplier with access to buyers interested in the 
category of goods offered by the supplier. 

In addition, when a supplier is asked to submit a bid, the supplier must assemble 
the appropriate information and submit it to a potential purchaser. If the supplier submits 

1 5 bids to many different purchasers, the supplier must maintain records that identify which 
bids were submitted to which purchasers and track key dates such as the date that a bid 
must be submitted, the date that a purchaser will make a purchasing decision or award 
a contract, and so forth. 

Purchasers face problems somewhat analogous to those of suppliers. Purchasers 

20 wish to collect information from suppliers that offer goods or services of interest to the 
purchaser- In addition, purchasers may wish to disseminate information regarding the 
types of goods or services needed by a particular purchaser. Furthermore, purchasers 
must have the ability to communicate with one or more suppliers in order to solicit bids, 
receive bids from suppliers, and analyze and compare the information in the various bids. 

25 Moreover, purchasers must also be able to track critical information such as the deadline 
for submitting bids, the date for making a decision, and so forth. In addition, many 
purchasers have procurement policies and procedures that must be followed during the 
procurement of goods or services. 

With the vast amount of information that must be exchanged between a purchaser 

30 and one or more suppliers, there have been various attempts to automate or facilitate the 
process using today's communication technology. For example, online catalog systems 
exist that allow a potential purchaser to browse through an online or electronic catalog, 
receive information about particular products or services offered, and place orders for 
those products with a particular supplier. 

35 Some suppliers have recognized the value of using electronic mail to 

communicate with potential customers and have begun to broadcast information to 
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potential purchasers. This practice has given rise to the so called "junk" E-mail received 
by many and is ineffective, inefficient, and irritating unless carefully filtered towards 
appropriate recipients. Unfortunately, none of the systems presently in place support all 
aspects of the procurement process and facilitate both the dissemination of information 
and the tracking of responses. For example, although it is known to broadcast E-mail 
messages to a plurality of recipients, no coherent mechanism exists that allows collection 
of responses from a plurality of individuals. As a result, even if a buyer used electronic 
mail to broadcast a request for a bid to a plurality of suppliers, there would be no way to 
track the responses to that request and easily assemble the information from the suppliers 
so that it can be compared and analyzed. What is needed, therefore, is a system that 
facilitates the tracking and collection of responses from a plurality of sources so that 
information relating to a particular bid may be collected from various suppliers and 
analyzed. 

As previously mentioned, the bid process requires that certain dates be tracked 
and deadlines identified. Present E-mail systems do not allow for the tracking of 
deadlines. When an E-mail messages arrives at a particular location, a user is free to read 
or ignore the message as they wish. Furthermore, the only mechanism that exists for 
identifying desired reply dates is to include such information into the text or body of the 
E-mail message. It would be desirable to have a system that could remind people of 
approaching deadlines so that they would not be forgotten. 

A buyer seeking to purchase an item from a supplier electronically may have 
several concerns with the proximity of the buyer's business to the supplier's business, 
particularly in regards to service contract items that might require local support. Buyers 
are also worried about the quality of goods that are being sold across the electronic 
community. Traditionally, a buyer is able to inspect the goods prior to making a purchase 
and most traditional electronic commerce methods, or those methods in place today, do 
not allow the buyer to inspect the goods. Finally, the price that is often offered across the 
internet is higher that a buyer might be able to obtain with direct contact to the supplier. 
The reason for this increased price level is that the price posted over the internet must be 
the common price of the supplier and does not take into account discounts that the 
supplier might be willing to grant to a particular buyer of a particular product or at a 
particular quantity level. Another problem faced by the buyer desiring electronic 
commerce is the considerable delivery delay between their purchase of an item and the 
completion of the purchase transaction. What is needed is a system that allows a buyer 
to choose a group of suppliers for which it desire to send out a request for a bid. 
According to the proximity of the supplier, the quality of goods of the supplier, and the 
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price discounts might be offered by the supplier for various quantity purchases. And 
finally, such a system would be improved if a tracking system were in place concerning 
the delivery of the item following the decision to make a purchase. 

Another popular method of automating purchasing transactions utilizing modern 
5 electronic communication techniques is through electronic auctions. Unfortunately, 
electronic auctions do not provide many of the merchant safeguards needed as part of a 
continuous purchasing process. For example, participants in an auction setting are 
subject to a variable sales price dictated by the number of buyers involved in each auction 
and to a variable quantity of product available for auction. Further limitations include the 

1 0 lack of stable purchase contracts, product quality assurances, and customer service. Also, 
an auction setting does not allow vendors and suppliers to provide specific buyers with 
preferred customer discounts, tiered pricing, and quantity discounts. Additional problems 
exist with payment and delivery of the auctioned items, resulting in the need to use 
escrow agents and other third parties to monitor the purchase transaction. Not only does 

1 5 this increase the time necessary to complete the transaction, but each of these limitations 
increase the overall cost of doing business electronically. In many cases, the safeguards 
and shipping fees associated with electronic auction purchases are more expensive than 
the actual product being purchased. What is needed is a method of facilitating a purchase 
transaction that allows both the buyer and supplier to selectively join a submarket with 

20 other similarly situated or trusted market participants, thereby eliminating the extra costs 
and variable costs presently associated with electronic auctions. 

The emergence of the internet as a commerce facilitator has influenced the 
development efforts of interactive purchasing and bidding systems within the 
procurement industry. The industry is dominated by market participants who are 

25 focusing their efforts towards the development of pure Web Browser based procurement 
systems. Unfortunately, these procurement systems are hampered by a variety of 
significant technological limitations introduced when a program is limited to browser 
technology. For example, procurement data transfers made using browser technology 
must be of a limited size to ensure hardware and software compatibility with users using 

30 slow telephonic internet connections. Many internet service providers limit the access 
time that any particular user may utilize a specific telephonic connection, if the download 
times associated with the exchange of procurement information exceed these limitations 
the data transfer is often cut off. As a result systems requiring large data transfers 
become prohibitive to users using telephonic connections. Unfortunately, the data 

35 transfers must also be quick and efficient so that the individual making the request for 
bids is not swamped by the responses to his request. Additional delays in communicating 
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with the requestor are introduced when large data modules are necessary, further 
hamperinglhe quality of the commerce transaction and amplifying the time limitations 
previously discussed. Finally, Browser technology requires secured data transfers to be 
transferred in an encrypted but uncompressed format, thereby increasing the size of the 
5 transfer because of the lack of data compression and lowering the connection speed due 
to the added overhead associated with browser based data encryption. Therefore, a 
procurement system based on pure browser technology emphasizes the worst traits of the 
internet. What is needed is a system that is not limited by the constraints of modern 
browser technology, but still takes advantage of the available compression and encryption 
10 protocols without limiting the outstanding contact and connection opportunities created 
by the internet. 

In summary, a system does not presently exist that facilitates all aspects of the 
procurement process by supporting efficient information exchange between suppliers and 
buyers. Furthermore, systems do not exist that allow a buyer to transmit information to 

15 a plurality of suppliers and collect and manage responses from suppliers so that the 
information contained therein can be analyzed and compared. In addition, systems do not 
exist that allow tracking of critical dates and deadlines and that facilitate reminding 
individuals of key dates and deadlines. Additionally, systems do not exist that allow 
market participants to selectively create submarketplaces of approved buyers and 

20 suppliers to reduce costs and ensure quantity and quality levels for products being 
purchased. Finally, systems do not exist that take advantage of available compression 
and encryption protocols without limiting the outstanding contact and connection 
opportunities created by the internet. 

SUMMARY OF THE INVENTION 

25 The foregoing problems in the prior state of the art have been successfully 

overcome by the present invention, which is directed to a system and method for 
coordinating purchasing communications and tracking responses. The system and 
method of the present invention is fully scalable in that the system and method can be 
adapted to accommodate an unlimited number of suppliers and buyers in the electronic 

30 community. Furthermore, the invention allows exchange of information between buyers 
and suppliers not only during the bidding process but prior to the bidding process as well. 
In fact, the exchange of preliminary information allows buyers and suppliers to 
selectively create specific private submarketplaces from the unlimited number of 
suppliers and buyers in the electronic community. 

35 A marketplace administrator can create a virtual marketplace by inviting specific 

buyers and suppliers from the general electronic community to join the proposed 
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submarketplace. The advantage of such a system is that multiple, smaller groups or 
submarketplaces may be created by individual entities within the electronic community. 
These submarketplaces are often referred to as electronic marketplaces or virtual 
marketplaces. The focus of each submarketplace is to promote commerce between 
5 members. To promote procurement transactions, the community owner or marketplace 
administrator controls the transactional fees and controls the membership within the 
community. For example, a chamber of commerce may invite its members and selected 
suppliers and buyers who have ties to the community to participate in the chamber of 
commerce's electronic marketplace. Participating in the electronic marketplace provides 

10 members of the chamber of commerce with an efficient way to support each other 
through electronic purchasing, as buyers and suppliers. Membership in the electronic 
marketplace does not exclude individuals from also participating in the larger electronic 
commerce groups for items that are not available or are not offered at a reasonable price 
by suppliers within the electronic marketplace created by the chamber of commerce. 

1 5 Under these circumstances, a submarketplace allows suppliers to offer better prices to the 
selected buyers than they might offer to the general public and provides buyers with 
filtered information pertinate to their desired purchasing transactions and provides buyers 
with filtered information relative to their purchasing activities. 

The system and method of the present invention utilize a service provider that 

20 maintains a central database of information about various buyers, suppliers, products, and 
services. The information about each potential marketplace participant is stored in a data 
object that is electronically updated by the marketplace participant, the marketplace 
administrator, or the service provider. All data objects may be grouped by classifications 
and/or products or product lines. Once a marketplace participant accepts membership 

25 into the new marketplace, portions of the information contained in the participant's data 
object are attached to the marketplace object. Buyers or suppliers may extract 
information from the marketplace object in order to identify goods or services that are 
available or desired in the marketplace. Thus, buyers may retrieve information about 
suppliers and products or services offered for sale. Suppliers, on the other hand, may 

30 retrieve information about buyers in order to target advertising or other information 
relating to critical accounts. Such information may also allow suppliers to tailor their 
goods or services in order to better suit the needs of particular purchasers. Marketplace 
administrators may retrieve information about suppliers and buyers to create other private 
virtual marketplaces that center to the specific needs of the suppliers and buyers. Under 

35 these circumstances suppliers may be willing to offer better prices and more flexible 
terms to the selected buyers. At the same time, the buyers in the virtual marketplace may 
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agree to longer or larger purchase contracts with the supplier. Often the parameters of 
the electronic marketplace created by the marketplace administrator will offer additional 
quality control to both the supplier and the buyer. 

Other purchasing functions offered by the present invention outside of the bidding 
5 and request for bids include single stop purchase orders, electronic shopping carts, and 
proxy marketplace catalogs where multiple suppliers can coordinate with multiple buyers 
through a single electronic proxy. For example, there are situations where pro-consumer 
groups certify a group of suppliers as approved to provide services to their buyers. The 
buyers look to the pro-consumer group as a source for choosing quality suppliers. Using 

1 0 the present invention, the pro-consumer group could create a marketplace with various 
product categories containing all of the approved suppliers and all of the buyer members 
of the group. Thereby creating a multiple supplier to multiple buyer marketplace to 
facilitate purchasing transactions. Suppliers in this marketplace could be removed if they 
lose their certification or the marketplace administrator could limit the number of 

15 products offered by the supplier to those products meeting the pro-consumer group's 
quality standards. 

Prior art programs do not allow for the creation of dynamic commerce 
environments where marketplaces can be created on demand by members who are 
subscribers to the larger group or by an outside regulating entity. The present invention 

20 allows all of the subscribers to utilize the present invention to create opportunities for 
commerce between the participating buyers and suppliers. One embodiment of the 
present invention uses a combination of database and Internet technologies to provide 
effective sourcing, bidding, purchasing, and messaging between buyers and suppliers. 
By installing a software component directly onto the user's machine, one embodiment of 

25 the present invention is able to implement a data pipe solution using common Active 
Data Object (ADO) technologies. The component is a purchasing program using ODBC 
compliant databases and internet communication technologies to increase the data 
transfer rates between various users within the system. By expanding beyond pure 
browser based communication, the present invention can export bid information between 

30 suppliers, buyers, and other systems using standard internet data files, ASCII, EDI, 
ODBC, or Excel file formats. A component object model (COM) allows participants 
access to data through standard Microsoft® programming interfaces, meaning that 
marketplace participants can send files using any format or file type that the participant 
desires, although the use of standard file types or typical internet protocols such as .xls, 

35 .doc, .bmp, .gif, jpg, or .htm, is preferred. Many of these file types include some form 
of compression which can significantly reduce the number of bytes needed to transfer 
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between parties participating within the marketplace. Encryption can then be conducted 
on the compressed files adding additional security to the data transmissions. An example 
of the typical encryption standard used in the present invention is 128 bit using SSL 
certificates from VeriSign, Inc., however, it is clear that enhanced or relaxed encryption 
5 standards could be applied to the present invention without affecting the objects and 
advantages over similarly protected procurement systems. 

The present invention supports a bidding process that may be summarized as 
follows. A vendor enters information into the database in order to allow potential buyers 
to identify the various products or services offered by the vendor. The vendor can submit 

1 0 company profiles which describe the company. The vendor may also submit information 
on products or product lines offered for sale. The company and product lines may be 
grouped into various classifications in order to help purchasers locate suppliers of a 
particular type or class of goods or services. The vendors may submit this information 
to the database through electronic means, such as the internet, or through paper of fax if 

1 5 the vendor has no electronic link to the service provider. Buyers may also submit similar 
types of information to allow suppliers to identify information about particular buyers and 
about the goods or services that are needed or required by a particular buyer. The 
submitted information may be updated as often as a buyer or supplier wish in order to 
maintain currency. 

20 The service provider collects submitted information and stores it into a database 

organized to allow rapid access to desired information. Such a database may be stored 
in a single central location where vendors and buyers may dial in and access the database, 
or copies of portions of the database may be distributed to marketplaces, buyers, and 
suppliers as desired. Such a distributed database method may be preferred in order to 

25 allow rapid access to information by a buyer or supplier without the need to contact a 
centralized database location. If such a distributed database is used, mechanisms can be 
put in place in order to update the local databases stored by the suppliers or buyers. An 
essential aspect of the marketplace configuration is the ability of participating suppliers 
or buyers to modify information from the database for exclusive display within the 

30 marketplace, for example, adjusting the normal product list and discounts offered. This 
allows the marketplace object containing product pricing information to vary from the 
information held in a central or regional database. 

When a buyer wishes to purchase goods or services or request a bid from various 
suppliers for particular goods or services with a marketplace, the buyer can browse the 

35 marketplace object using various criteria. For example, the buyer may select suppliers 
by company name, by key words, by classifications, or any other manner that allows rapid 
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access to desired information. As the buyer browses the marketplace object, the buyer 
can assemble a list of suppliers that will receive a request for a bid within the 
marketplace. If the buyer has not previously joined a marketplace containing the relevant 
suppliers, the buyer may initiate a search of the database to assemble a list of suppliers. 
5 Once this selection is made the buyer can either send a request for bid to the suppliers or 
create a new marketplace including the suppliers and make the request within the 
marketplace. The buyer may decide that the transaction is merely a one time purchase, 
calling for a direct request for bid sent to the supplier. Alternatively, the buyer may 
decide that the proposed purchasing transaction would be better received by a new 
1 0 marketplace. The buyer creates the marketplace and invites the list of suppliers to j oin the 
marketplace. One advantage of this configuration is that the buyer may have similar 
periodic purchasing transactions and the marketplace would already be created for the 
next transaction. 

After the buyer has selected a list of suppliers, the buyer creates and sends a "data 

1 5 cast" message. A data cast message is a message that will be broadcast to the selected 
suppliers requesting a bid on desired goods or services. A data cast message may contain 
such information as a text message, dates of importance including the date that the data 
cast message was sent, the date that a response is due, and the date that one or more 
reminders will be sent. The data cast message may also contain attached documents such 

20 as specifications, scanned pictures, or any other type of electronic or scanned document. 
The data cast message may also contain a series of prompts entered by the buyer. These 
prompts are used to prompt a supplier for information that should be returned with the 
bid. For example, prompts can include such information as the total parts cost, the total 
labor cost, miscellaneous charges, amount of goods supplied, total bid cost, or any other 

25 type of information desired by a buyer. These prompts are text strings and there is no 
limit on the text of prompt. Thus, a buyer is free to request information in categories that 
he or she desires to compare from various suppliers. 

In addition to the data cast message, the buyer also creates a data cast object. The 
data cast object serves as a central unit of information that contains not only the data cast 

30 message, but also responses received from various suppliers. Thus, when the data cast 
object is created, the data cast object has locations set aside to store information from the 
responses that will be received from the various suppliers. Such an approach differs 
significantly from the prior art and provides advantages not available in the prior art. As 
responses are received from various suppliers, they can be stored in the data cast object. 

35 The data cast object thus can be passed from one individual or organization to another 
and will contain all information relating to a particular bid. The present invention allows 
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not only broadcast of information but also tracking and storage of responses in a manner 
that minimizes the likelihood of lost information. 

After the buyer creates the data cast message and data casr object, the buyer sends 
the data cast message to the suppliers previously identified by browsing the database. In 
5 a preferred embodiment, all communication between a buyer and the suppliers is 
performed electronically. Such electronic communication allows automation of 
responses and automatic storage of responses into the data cast object as explained. 
However, for those suppliers who do not have access to electronic communications, the 
data cast message can be sent via facsimile or printed and mailed in an envelope. It 

1 0 should be noted that a buyer is free to update a data cast at anytime. Such an update will 
necessarily generate an updated data cast message. The updated data cast message can 
be sent to suppliers as previously described. Such an updated data cast message 
supersedes and replaces any previous messages. 

When vendors receive a data cast message from a buyer, the vendors may store 

15 the data cast message in a response database. This allows vendors to track important 
information and dates received from a plurality of buyers. If a vendor receives a data cast 
message via E-mail or other electronic communication, when the vendor opens the 
document, the information contained in the data cast message is displayed to the supplier. 
The displayed information includes the sequence of prompts previously described. This 

20 allows a vendor to submit information desired by a particular supplier. The vendor may 
also include additional information such as text and/or scanned or electronic documents. 
After the vendor has assembled his or her bid, the vendor can respond using E-mail. If 
a vendor does not have access to electronic communications, then fax, printed letters or 
telephone calls may be substituted. However, such methods are not preferred since it 

25 does not allow automated storing of responses. 

As responses are received from various suppliers, the buyer gathers the responses 
and stores information from the responses into the data cast object previously created. 
As previously explained, by storing the response information into the data cast object, a 
single contained unit of information is created that allows analysis and comparison of the 

30 received responses. An analogy to the data cast object may be a folder or file where all 
information received regarding a particular bid can be placed. The file can then be 
carried from one individual or location to another and will contain all information 
necessary to process and analyze the various responses received. Using a data cast object 
also opens up a wide variety of options. For example, the buyer may choose to collect 

35 information and store it into the data cast object. On the other hand, the buyer may 
choose to pass the data cast object to the service provider and allow the service provider 
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to collect responses from the suppliers and store them into the data cast object. The 
service provider can then be responsible for other tasks such as sending out reminders, 
following up on suppliers that have not responded, and so forth. Once all information has 
been collected into the data cast object, the service provider can pass the data cast object 
5 to the buyer for analysis. 

Because all information relating to a particular bid is stored in a single data cast 
object, it is easy to send follow-up reminders at designated times in order to ensure that 
deadlines are not missed. For example, the original data cast message created by a buyer 
may contain dates for one or more reminders to be sent to the suppliers. As these dates 

1 0 approach, the system can automatically send a reminder to those suppliers that have not 
yet responded to the bid request. As previously described, such reminders may be sent 
by anyone who has the data cast object. 

After all information has been gathered and placed into the data cast object, the 
buyer can then analyze the information received. For example, information stored in the 

1 5 data cast object may be extracted and sent to an analysis module for comparison. Since 
a data cast message contains a series of prompts used by suppliers when responding, the 
informatiqn or responses to the series of prompts may be extracted and placed into a 
spreadsheet program. The various bids may then be compared and analyzed using the 
spreadsheet program. Other types of analysis modules may also be used or developed in 

20 order to analyze the responses received from the various suppliers. 

An alternative embodiment allows a trading partner or administrator to create a 
submarketplace with controlled pricing capabilities including at least one buyer and at 
least one supplier selected by the trading partner from a database of general subscribers 
to the larger electronic commerce communication system. The pricing capabilities 

25 controlled by the trading partner include establishing association costs and individual 
transaction fees within said submarketplace. The trading partner may also require a flat 
fee, a graduated fee, or a transactional fee from the supplier or the buyer for any 
successfully completed purchasing transaction. Selection of the suppliers may be made 
by the trading partner according to product pricing, quantity and quality information or 

30 geographical information extracted from a supplier data cast database. Buyers may be 
selected by the trading partner based on purchasing infoimation extracted from a similar 
buyer data cast database of general subscribers to said electronic commerce 
communication system.The submarketplace utilizes the data cast object to exchange 
product and pricing information between buyers and suppliers within the submarketplace. 

35 The trading partner may also choose to pass the data cast object to the submarketplace 
and allow the submarketplace to collect responses from the suppliers and store them into 
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the data cast object. The submarketplace can also be responsible for other tasks such as 
sending out reminders, following up on suppliers that have not responded, and so forth. 
Once all information has been collected into the data cast object, the submarketplace can 
pass the data cast object to the buyer for analysis. Once the parties have reached an 
agreement, the submarketplace permits the exchange of purchasing information between 
the buyer and the supplier. The purchasing information exchanged between the buyer and 
the supplier may include at least one electronic purchase order form. Multiple electronic 
purchase order forms may be generated from a single marketplace purchase order form. 
The multiple purchase order forms are then distributed to selected suppliers as dictated 
by the original buyer's purchase selections, each electronic purchase order form indicating 
only the information corresponding to the purchase transaction between the buyer and the 
specific supplier The submarketplace continues to track the progress of the purchasing 
transaction through the data cast object until receiving verification that desired product 
is received by the buyer from the supplier. 

Accordingly, it is a primary object of this invention to provide a system and 
method for communication coordination and response tracking that facilitates all aspects 
of the bid process from initial selection of products or suppliers through analysis of 
responses. Other objects of the present invention include: providing a system and 
method for communication coordination and response tracking that uses a centralized 
repository of information to collect responses received; providing a system and method 
for communication coordination and response tracking that allows a buyer to customize 
the information requested by entering a sequence of prompts; providing a system and 
method for coordinated communication and response tracking that allows information 
received in responses to be placed into an analysis module in order to analyze and 
compare responses; providing a system and method for coordinating communication and 
response tracking that facilitates exchange of information between a plurality of buyers 
and a plurality of suppliers; providing a system and method for communication 
coordination and response tracking that allows market participants to selectively create 
marketplaces of approved buyers and suppliers from a larger plurality of buyers and a 
larger plurality of suppliers to reduce costs, increase efficiency of marketing efforts, and 
ensure availability of desired quantity and quality levels for products being purchased; 
providing a system and method for coordinating communication and response tracking 
that use available compression and encryption protocols while maintaining internet 
compatibility; and providing a system and method for coordinating communication and 
response tracking that promotes the creation and administration of submarketplaces 
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within the larger electronic community featuring controlled pricing and selective 
membership. 

Additional objects and advantages of the invention will be set forth in the 
description which follows, and in part will be obvious from the description, or may be 
5 learned by the practice of the invention. The objects and advantages of the invention may 
be realized and obtained by means of the instruments and combinations particularly 
pointed out in the appended claims. These and other objects and features of the present 
invention will become more fully apparent from the following description and appended 
claims, or may be learned by the practice of the invention as set forth hereinafter. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

In order that the manner in which the above-recited and other advantages and 
objects of the invention are obtained, a more particular description of the invention 
briefly described above will be rendered by reference to specific embodiments thereof 
1 5 which are illustrated in the appended drawings. Understanding that these drawings depict 
only typical embodiments of the invention and are not therefore to be considered to be 
limiting of its scope, the invention will be described and explained with additional 
specificity and detail through the use of the accompanying drawings in which: 

Figure 1 is a top level diagram of one embodiment of the present invention; 
20 Figure 2 is a diagram illustrating a distributed database accessed by buyers and 

suppliers of the present invention; 

Figure 3 A and 3B are a top level flow diagrams of one embodiment of the present 
invention; 

Figure 4 is a flow diagram illustrating the details of one implementation of the 
25 local database maintenance processing block of Figure 3 A; 

Figure 5 is a flow diagram of one implementation of the data cast creation 
processing block of Figure 3 A; 

Figure 6 is a flow diagram illustrating one implementation of the supplier 
communication processing block of Figure 3 A; and 
30 Figure 7 is a flow diagram illustrating one implementation of the data cast 

analysis block of Figure 3 A; 

Figure 8 is a flow diagram illustrating the details of new member creation, new 
marketplace creation, and general electronic community solicitation of one 
implementation of the present invention; 
35 Figure 9 is a top level diagram of one electronic marketplace embodiment of the 

present invention. 
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DETAILED DESCRIPTION OF THE P REFERRED EMBODIMENTS 
The following invention is described by using flow diagrams to illustrate either 
the structure or the processing of certain embodiments that implement the system and 
method of the present invention. Using the diagrams in this manner to present the 
invention should not be construed as limiting of its scope. The present invention 
contemplates both systems and methods for coordinating communication and response 
tracking. Embodiments of systems of the present invention may comprise a general 
purpose computer. Such a general purpose computer may have any number of basic 
configurations. For example, such a general purpose computer may comprise any or all 
of a central processing unit (CPU), one or more specialized processors, system memory, 
mass storage such as a magnetic disk, an optical disk, or other storage device, an input 
means such as a keyboard and/or mouse, a display device, and a printer or other output 
device. A system implementing the present invention can also comprise a special 
purpose computer or other hardware system and all should be included within its scope. 

Embodiments within the scope of the present invention also include computer 
readable media having executable instructions. Such computer readable media can be 
any available media which can be accessed by a general purpose or special purpose 
computer. By way of example, and not limitation, such computer readable media can 
comprise RAM, ROM, EEPROM, CD ROM or other optical disk storage, magnetic disk 
storage or other magnetic storage devices, or any other medium which can be used to 
store the desired executable instructions and which can be accessed by a general purpose 
or special purpose computer. Combinations of the above should also be included within 
the scope of computer readable media. Executable instructions comprises instructions 
and data which cause a general purpose computer or special purpose computer to perform 
a certain function or a group of functions. 

Turning first to Figure 1 , a top level diagram of the invention is presented. The 
present invention is designed to facilitate communication between a plurality of buyers 1 0 
and a plurality of suppliers 12. The invention supports a bidding process all the way from 
the initial selection of suppliers to the broadcasting of a request for bid, collection of 
responses from selected suppliers, and analysis and comparison of the responses received 
from the suppliers. 

Initial information about buyers 10 and suppliers 12 is exchanged via service 
provider 14. Service provider 14 collects information submitted by buyers 10 and 
suppliers 12 and stores the collected information into central database 16. As explained 
in greater detail below, central database 16 may contain information regarding a 
particular buyer or supplier as well as information regarding products or services needed 
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by a particular buyer or offered by a particular supplier. Information stored in central 
database 16 may preferably be accessed via key word, classifications, or any other 
manner that allows easy access by a buyer or supplier to the information stored in central 
database 16. 

The information stored in central database 16 may be accessed through service 
provider 14 or, alternatively, a portion of the information in central database 16 may be 
copied by a buyer 10 or supplier 12 into a local database such as local database 18 or 
local database 20. In some embodiments, it may be preferable to distribute portions of 
central database 16 to various local databases, such as local database 18 or local 
database 20. This will allow a buyer or supplier to access desired information locally 
rather than establishing contact with service provider 14 in order to access central 
database 16. Such a distributed database model often gives faster access to desired 
information, but introduces the additional complexity of maintaining current copies of 
local databases in a variety of locations. However, particular buyers or suppliers may 
wish to assume a larger share of the maintenance responsibilities for faster access to 
desired information. 

As explained in greater detail below, the present invention facilitates 
communication between buyers 10 and one or more suppliers 12. Such communication 
may be achieved through service provider 14 as indicated in Figure 1, or may be direct 
from a buyer to one or more suppliers as indicated by arrow 22. These various options 
are explained in greater detail below but it is important to recognize that the present 
invention is highly flexible in this area and provides many capabilities not available using 
prior art technology. 

Although the process of soliciting bids and collecting responses using the present 
is described in greater detail below, the process may be summarized as follows. 
Supplier 12 submits information to service provider 14 to be included in central 
database 16. Such information may include, for example, company profile information 
describing the company. Classification information may also be submitted illustrating 
the types or classes of services or goods provided by a particular company. Additionally, 
supplier 12 may also submit information regarding the products, product lines, services, 
and the like offered by the supplier. Classification information for the products and/or 
services offered by a particular supplier may also be submitted. In short, supplier 1 2 may 
submit any information into central database 16 that would be helpful for a buyer in 
locating aod selecting supplier 12. In certain embodiments, it may be desirable to limit 
the type of information submitted by a supplier to a predefined set of fields in order to 
provide consistency and uniformity in central database 16. In other embodiments, 
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perhaps a selected set of information must be submitted with the option of submitting 
additional information as well. In the present invention, central database 16 serves as a 
repository /or information useful in allowing buyer 10 to locate suppliers 12 that offer 
goods or services of interest. 

5 In addition to storing information relating to suppliers, central database 16 may 

also store information relating to buyers. Thus, buyer 10 may also be allowed to submit 
information to be stored in central database 16. Such information may include, for 
example, company profiles containing information about the company. Additionally, a 
company may submit classifications of goods or services that are routinely purchased or 

1 0 desired by a particular buyer. In addition, more detailed information regarding the types 
of goods or services purchased by a particular buyer may also be submitted. Again, 
central database 16 may store any information that would be useful in allowing 
supplier 12 to locate buyers of interest. In some embodiments it may be desirable to 
allow buyer 10 to submit any type of information. In other embodiments, it may be 

1 5 desirable to require buyer 1 0 to submit certain information with the option of submitting 
additional information. In other embodiments, perhaps only a predefined set of 
information is submitted by a buyer. Including buyer information into central database 1 6 
allows supplier 12 to browse central database 16 in order to identify the goods or services 
desired in the marketplace. This may allow a supplier to gauge the size of a particular 

20 market or may allow a particular supplier to locate and contact buyers wishing to 
purchase specific goods or services. In addition, such information may allow supplier 12 
to tailor goods or services to the particular needs of a segment of the market. 

A buyer wishing to purchase goods or services may browse central database 16 
or a local database, such as local database 18, in order to identify suppliers that offer 

25 goods or services of interest to the buyer. Buyer 10 may assemble a list of suppliers of 
interest. Buyer 10 may then use this list to distribute information to suppliers, either 
directly or indirectly through service provider 14. In other embodiments, the list of 
suppliers may be used by the marketplace administrator to specify invited members of a 
private marketplace created by the buyer. As explained in greater detail below, the 

30 present invention allows not only for an initial broadcast message requesting bids for 
goods or services, but also facilitates sending follow-up reminders in order to help 
suppliers remember approaching deadlines. 

Suppliers receiving a broadcast message requesting bid information will respond 
with the requested information. Responses are collected from various suppliers and 

35 stored together in order to keep all information in a single location. In some 
embodiments, buyer 10 may directly collect responses and assemble the appropriate 



WO 01/16826 m PCT/US00A18943 

17 

information. In other embodiments, such actions may be performed by service 
provider 14. Still other embodiments have the marketplace object or marketplace 
administrator performing these actions. In these embodiments, after all information has 
been collected and assembled, the information may then be transferred to buyer 10. 
5 Buyer 10 can then examine and analyze the information in order to make purchasing 
decisions. 

Turning next to Figure 2, an embodiment is illustrated showing the database 
structure of the present invention and the relationship between central database 16 and 
local databases, such as local database 34 and local database 36. As previously illustrated 

10 in Figure 1 , service provider 1 4 maintains a central database, shown generally in Figure 2, 
as 24. Central database 24 can contain a wide variety of information useful to suppliers 
12 and buyers 10. As summarized above, and as explained in greater detail below, 
supplier 12 may use the infonnation stored in central database 24 to locate information 
about potential buyers of offered services or products. Buyer 10 may use the information 

1 5 in central database 24 in order to locate suppliers of goods or services. Thus, central 
database 24 may contain information that allow buyer 10 and suppliers 12 to accomplish 
their objectives. Although in certain embodiments, it is preferred that central database 24 
contain information regarding both suppliers and buyers, other embodiments of the 
present invention may contain only infonnation relating to suppliers or only information 

20 relating to buyers. Still other embodiments mandate that only the available goods or 
services be generally available and that the release of specific buyer and seller 
information be controlled by the marketplace parameters. 

Inmder to accomplish the objectives of providing information relevant to buyers 
and suppliers, central database 24 may contain company profiles of suppliers. This is 

25 illustrated in Figure 2 by suppliers information 26. Company profiles may contain any 
information necessary or useful for allowing a buyer to find more information about a 
particular supplier. For example, supplier profiles may contain such information as a 
supplier ID, the company name, the address of the company, various telephone numbers 
where the- company may be reached, whether the supplier is an "approved" supplier, 

30 contact information at the supplier, various text fields containing information such as a 
brief company profile, notes, and so forth. A wide? variety of additional information may 
be incorporated into a supplier profile. E-mail addresses, internet home pages URL, or 
any other type of information may be provided in a company profile. It is prefened, 
however, that as a minimum a supplier profile contain contact information, as well as 

35 addresses* telephone numbers, E-mail addresses, and so forth in order to allow a buyer 
to be able to contact a particular company. Furthermore, it is prefened that a company 
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profile have description information sufficient to allow a buyer to select a supplier from 
among other suppliers in the database. 

Some embodiments also support buyer profiles in central database 24. In 
Figure 2, this is illustrated by buyer information 28. Buyer information 28 represents the 
5 company profiles submitted by buyers into central database 24. Company profiles for 
buyers may contain similar information to the company profiles for suppliers. Thus, 
company profiles for buyers may contain, for example, company name, ID code, address 
information, telephone numbers, fax numbers, E-mail addresses, internet web page URL, 
contact information, and so forth. 

10 In order to help locate companies or products, central database 24 may also 

contain classifications. Such classifications are illustrated in Figure 2 by classification 
information 30. Such classifications may comprise, for example, a classification ID, a 
classification description, and other information necessary to identify a particular 
classification. Company profiles (either buyer or supplier) and products may then link 

1 5 to these various classifications in order to identify the classes of goods or services offered 
by a particular company. In the case of products or services offered by a company, 
linking them to a class will help locate groups or classes of products or services available 
in the database. 

Central database 24 may also comprise product information. This is illustrated 

20 in Figure 2 by product information 32. Such product information may contain a product 
ID, a supplier ID (in order to identify the supplier that offers this particular product and 
link the product to the supplier), an item number or ID, a description, price, class 
information, scanned photographs, audio clips, video clips, and any other type of 
information necessary to identify a particular product in the database. In one embodiment 

25 of the present invention, companies may submit product information for all products or 
services offered by the company. In other embodiments, it may be desirable to limit the 
information in product information 32 to information about particular product lines. By 
requiring or allowing companies to submit information on product lines, the overall 
amount of information in the database may be reduced without limiting the ability of 

30 suppliers or buyers to identify the products or services offered or required. 

In some embodiments of the present invention, central database 24 may be the 
only database in the system and all requests for information may go to the central 
database. In other embodiments, it may be desirable to distribute some of the information 
in central database 24 to local databases. In Figure 2, such local databases are illustrated, 

35 for example, by local database 34 and local database 36. Local database 34 represents 
a local database used by supplier 12 in order to access relevant information. Local 
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database 36 represents a local database accessed by buyer 10 to retrieve relevant 
information. Referring first to local database 34, local database 34 may comprise 
relevant buyer profile information. Such information is represented in Figure 2 by buyer 
profile information 38. Buyer profile information 38 contains the local buyer information 
desired by supplier 12. Thus, buyer profile information 38 may represent a subset of 
buyer profile information 28 of central database 24. In addition to buyer profile 
information 38, local database 34 may also comprise product information 40 and 
classification information 42. Like buyer profile information 38, product information 40 
and classification block 42 also represent a subset of the information contained in central 
database 24. 

In some embodiments, it would be desirable to allow supplier 12 to select 
information contained in local database 34. Thus, supplier 12 may be allowed to browse 
central database 24 and identify those records that should be downloaded to local 
database 34 for local access. In other embodiments, it may be more desirable to 
download all buyer information to supplier 12. Still other embodiments allow a solicited 
participant to determine how much of their record is included in the local marketplace 
database through the marketplace object. Such details are considered to be 
implementations specific and not critical to this invention. All that is required is that 
local database 34 contain that information necessary or desired by supplier 12. 

Local database 36 contains all information needed or desired by buyer 10. Thus, 
local database 36 may comprise supplier profile information 44, product information 46, 
and classification information 48. Supplier information 44, product information 46, and 
classification information 48 may represent a subset of the information contained in 
central database 24. As previously explained, by keeping a copy of information locally, 
access to the information may be speeded up. 

In order to maintain central database 24, local database 34, and local database 36, 
a mechanism must be put in place that allows buyer 10 and supplier 12 to submit 
information to central database 24 and that allows buyer 10 and supplier 12 to receive a 
subset of the information contained in central database 24. In Figure 2, this mechanism 
is illustrated, for example, by database access/update processing block 50. Database 
access/update processing block 50 represents a process running on service provider 14, 
that maintains central database 24 and sends information to supplier 12 and buyer 10 for 
their respective local databases. 

Information may be submitted by supplier 12 and buyer 10 to central database 24 
through database update messages. In Figure 2, such messages are illustrated, for 
example, by database update message 52. Database update message 52 may contain any 
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information that a supplier, or buyer wishes to submit to central database 24. Such 
information may comprise, for example, the company profile information previously 
described, the classification information previously described, or the product information 
previously described. The format of database update message 52 is not critical and it 
5 does not matter whether a single universal message is used or whether specific messages 
are used for the various types of information that are submitted to central database 24. 

When database access/update processing block 50 receives database update 
message 52, database access/update processing block 50 extracts the appropriate 
information from database update message 52 and places the information into central 

1 0 database 24. Upon submission of new information into central database 24, suppliers or 
buyers interested in that record may be informed that new information has been added to 
central database 24. Such a mechanism may be useful, for example, to ensure that a local 
database has the most current information available in central database 24. 

As illustrated in Figure 2, messages exchanged between buyer 10, supplier 12, 

1 5 and service provider 14 travel across transport link 54. Transport link 54 represents an 
example of means for transferring information. Transport link 54 is intended to illustrate 
a generic transport mechanism and not any particular type of transport. It is preferred, 
however, that transport link 54 be an electronic communication medium. This allows 
messages exchanged between supplier 12, buyer 10, and service provider 14 to flow 

20 electronically without the need to manually enter information into central database 24, 
local database 34, or local database 36. If, however, a particular supplier or buyer does 
not have access to an electronic transport medium, then facsimile, telephone, or paper 
mail may bfe used to exchange appropriate information. Such a transport mechanism will, 
however, necessitate the entering of information into the appropriate database by hand. 

25 It is anticipated that most, if not all, communication will be electronic due to the 
widespread availability of electronic communication media including the internet, local 
area networks, wide area networks, dial-up communications, and other electronic 
communication means. 

In order to update a local database, supplier 12 or buyer 10 may issue an 

30 information request. Such an information request is illustrated in Figure 2 by information 
request message 56. Information request message 56 may be a request to update a 
portion or all of the appropriate local database. For example, in the embodiments where 
a supplier or buyer selects the information that is contained in its local database, 
information request 56 may identify those records of database 34 that are to be checked 

3 5 for currency. On the other hand, if the embodiment requires that a local database contain 
all appropriate information from central database 24, then information request 56 be 
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interpreted to transfer all relevant information from local database 24 to the appropriate 
local database. 

In order to identify information that needs to be updated, embodiments within the 
scope of this invention may comprise means for identifying records that should be 

5 updated. Such a means may comprise, for example, a date stamp or other means to 
recognize the latest version of a database or a portion of a database. Alternatively, 
records may be compared for currency between database versions. It is, however, 
preferred that a simple mechanism be used in order to speed the process of maintaining 
a local database and keeping a local database current with respect to the central database. 

10 When database access/update processing block 50 receives information 

request 56, database access/update processing block extracts the appropriate information 
from central database 24 and returns that information to the buyer or supplier that 
requested it. Such information may be returned, for example, in database information 
message 58. Database information message 58 may comprise any information from 

15 central database 24 that needs to be transferred from service provider 14 to supplier 12 
or buyer 10. 

Although the description of maintaining a local database presented above has 
focused on a supplier or buyer requesting update of information from service provider 14, 
other mechanisms are also possible. For example, service provider 14 may keep track 

20 of the records in the various local databases. When new information is submitted that 
affects a particular record of the database, then the updated record may be automatically 
sent to the appropriate buyers or suppliers by service provider 14. Such an approach 
would eliminate the need for information request messages to update local databases. As 
another alternative, service provider 14 may periodically contact each supplier or buyer 

25 that maintains a local database and provide updated information. Other mechanisms are 
also possible and all that is required for the present invention is that the local database 
maintained by a particular supplier or buyer be able to be updated as new information is 
received by service provider 14. 

Referring now to Figures 3 A and 3B, a diagram illustrating one embodiment of 

30 the present invention is presented. The process of submitting requests for bids to 
suppliers and for receiving and tracking responses is presented in conjunction with 
Figures 3 A and 3B. In Figure 3 A, the details of the processing that occurs on buyer 10 
have been expanded. 

Embodiments within the scope of this invention may comprise means for 

35 maintainirig a local database. As previously explained, both buyers and suppliers may 
maintain local databases, such as local database 34 or local database 36 of Figure 2. In 
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Figure 3 A, the means for maintaining a local database is illustrated, for example, by local 
database maintenance processing block 60. Local database maintenance processing 
block 60 is responsible for maintaining local database 36. Although the details of local 
database maintenance processing block 60 are presented below, in essence, local database 
maintenance processing block 60 is responsible for requesting updates from central 
database 24* arid receiving update information and storing it back into local database 36. 
In Figures 3A and 3B, such a request is illustrated by local database update request 
message 62. As previously explained in conjunction with Figure 2, such a function may 
also be accomplished by using information request message 56. However, in the 
embodiment illustrated in Figure 3, infoimation request message 56 is illustrated for the 
purpose of indicating that specific information may be requested from central database 
24. Local database update request message 62, on the other hand, is a general message 
intended to update all information in local database 36. In other words, information 
request message 56 may be used in Figure 3 to request a new record from central database 
24. Local database update request 62 may then be used to maintain the requested records 
in a current state. 

Service provider 14 returns requested information in local database update 
information message 64 or database information message 58. Although embodiments 
within the scope of this invention will most likely attempt to minimize the number of 
different messages exchanged between service provider 14 and the suppliers and buyers, 
separate messages are shown in Figure 3 simply to illustrate that any number of messages 
may be defined in order to accomplish the purposes of the invention. 

When a buyer wishes to send a bid request message to one or more suppliers and 
receive information from them, the process starts with the buyer browsing a database 
containing information about suppliers and products. As previously explained, such a 
database may be local, such as local database 36, or may be a central database such as 
central database 24. In the embodiment illustrated in Figure 3, the buyer would access 
local database 36. The embodiments within the scope of this invention may therefore 
comprise means for accessing a database comprising information about suppliers and 
products offered for sale by the supplier. Any mechanism that allows accessing and 
browsing of an appropriate database can be used. In Figure 3A, such means is 
incorporated into data cast creation processing block 66. 

As explained in greater detail below, when a buyer wishes to send a request for 
bid information to one or more suppliers, a message and response tracking object is 
created. Embodiments within the scope of this invention may also, therefore, comprise 
means for creating a message and response tracking object In Figure 3A, such means is 
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also illustrated by data cast creation processing block 66. Although the details of data 
cast creation processing block 66 are presented below, the purpose of data cast creation 
processing block 66 is to allow a buyer to browse information in local database 36, select 
a list of suppliers to receive a request for bid, and create a message and response tracking 

5 object. A key difference between the present invention and the prior art is the use of a 
message and response tracking object as a central repository for all information regarding 
a bid and responses received from various suppliers. 

The process of creating a message and response tracking object is illustrated in 
Figure 3A. The message and response tracking object is an object that comprises the 

1 0 broadcast message that will be sent to one or more suppliers and one response tracking 
object for each of the suppliers that the broadcast message is sent to. The broadcast 
message contains the information sent to the suppliers about the bid and each response 
tracking object is adapted to store information received in response to the broadcast 
message. 

1 5 In Figure 3 A, a user creates a data cast message, such as data cast message 68. 

Data cast message 68 contains all the information that a supplier would need to respond 
to a particular bid. Such information is drawn, for example, from data cast information 
and message block 70. Data cast information and message block 70 represents 
information either retrieved or entered by a user in order to create data cast message 68. 

20 Data cast message 68 is the message that will be broadcast to each of the selected 
suppliers. Thus, data cast message 68 may contain any type of information that a supplier 
would need in order to respond to a request for bid. Such information may include, but 
is not limited to, identifiers indicating the sender, the data cast, the user, or any other type 
of identifiers needed in the data cast message. Data cast message 68 may also comprise 

25 date information. Such date information may comprise the date that the data cast 
message was created or sent, the date or dates that reminders should be sent to suppliers 
that have not yet responded, the due date of the bids, and any other dates that identify 
milestones or deadlines that should be met. Additional information that may be included 
in data cast message 68 may include a purchase order number, the subject of the bid, a 

30 message that is to be displayed to the supplier containing instructions or other 
information, the status of the bid, a sequence of prompts that are to be displayed, attached 
files representing additional information, specifications, scanned documents, etc., and 
information regarding the analysis module that will be used to analyze the responses. 
Although not all embodiments may require all these information fields, many data cast 

35 messages may contain this type of information. 
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One unique feature of the present invention is the ability for a user to enter a 
sequence of prompts that will be displayed to a supplier. The sequence of prompts 
represent individual data items that should be returned when the supplier submits his or 
her bid and can represent areas of comparison between competing bids. For example, 
such a sequence of prompts may comprise a parts subtotal, a labor subtotal, 
miscellaneous charges associated with the bid, a quantity or amount provided, the total 
price of the bid, or any other information that should be displayed to the supplier and that 
should be submitted by the supplier in response to the bid. In one embodiment, the 
sequence of prompts are text fields that are displayed to the supplier. In such an 
embodiment, the information requested by the prompt is limited only by the needs and 
desires of the buyer. Thus, a buyer can request any type of information in the prompts. 
As explained in greater detail below, the sequence of prompts can represent areas of 
comparison between bids and may be used by an analysis module for such a purpose. 

In addition to data cast message 68, the process of creating a data cast also creates 
a response tracking object for each of the suppliers that are to receive data cast 
message 68. In Figure 3A, such response tracking objects are illustrated by receiver 
objects 72. Receiver objects 72 allows information received in response to data cast 
message 68 to be stored into a message and response tracking object. Thus, receiver 
objects 72 may contain data fields needed to store any appropriate information received 
from a supplier in response to data cast message 68. For example, receiver objects 72 
may comprise ID information necessary to identify the data cast, the response, the sender, 
the supplier, or any other type of identifying information. Furthermore, receiver 
objects 72 may contain information about the company submitting the bid. Such 
information may comprise, for example, a supplier ID, company name, a contact name, 
address information, telephone number, E-mail, fax, or other information, a comment 
field, and any other type of information needed to identify the supplier. Additionally, 
receiver objects 72 may contain fields to store information requested by data cast 
message 68. Thus, receiver objects 72 may contain locations to store the responses to the 
various prompts sent in data cast message 68. Finally, if any analysis module is to be 
used, receiver objects 72 may contain information that allows such an analysis module 
to extract relevant information and analyze or display such information for analysis by 
a user. The use of an analysis module in conjunction with the present invention is 
described in greater detail below. 

After a user has browsed local database 36, selected a list of suppliers that are to 
receive a request for bid, created a data cast message, and created the appropriate number 
of receiver objects, the data cast message, and the receiver objects are assembled into a 
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message and response tracking object. In Figure 3A, such a message and response 
tracking object is represented by data cast object 74. Data cajt object 74 serves as a 
central repository for all information regarding a particular data cast. For example, data 
cast object 74 comprises data cast message 68 and receiver objects 72, one for each 
supplier that will receive data cast message 68. A good analogy of data cast object 74 is 
a folder or file that contains all information relating to a particular bid. Thus, as 
information Is sent and received that relates to a particular bid, such information may be 
placed into data cast object 74. 

After a user has assembled a data cast object, such a data cast object may be used 
to send and receive information to and from the identified suppliers. Embodiments 
within the scope of this invention, therefore, comprise means for sending broadcast 
information to identified suppliers. In Figure 3 A, such means is illustrated, for example, 
by supplier- communication processing block 76. Although the details of supplier 
communication processing block 76 are presented below, the main function of supplier 
communication processing block 76 is to handle all communication between a buyer and 
the suppliers that receive and respond to a particular dat? cast. Thus, supplier 
communication processing block 76 extracts data cast message 68 from data cast 
object 74 and broadcasts data cast message 68 to the identified suppliers. As responses 
are received from the identified suppliers, the response information is stored into data 
cast object 74 by supplier communication processing block 76. This process is illustrated 
in Figure 3 by response 78 being stored into data cast object 74. Supplier communication 
processing block represents one example of means for storing information from responses 
into a message and response tracking object. 

One of the problems in the prior art is the inability to track important dates. As 
previously described, data cast message 68, and data cast object 74 may contain critical 
date information such as the deadline for bids to be received and one or more reminder 
dates. This makes it extremely easy to generate reminder messages and broadcast them 
to those suppliers that have not responded to the bid request. In Figure 3A, supplier 
communication processing block 76 can monitor the dates in data cast object 74 and, 
when appropriate, generate reminder message 80 and broadcast reminder message 80 to 
those suppliers that have not yet responded by the reminder date. Such reminder 
messages may contain any appropriate information needed to remind a supplier of the 
deadlines. Such a reminder message may, therefore, vary anywhere from a simple 
reminder text message to a complete rebroadcast of data cast message 68. 

As previously explained, when a message and response tracking object, such as 
data cast object 74 of Figure 3 A is used, it makes it extremely convenient to extract 
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information received from various suppliers and to compare and analyze the information 
in order to arrive at the best purchasing decision. Thus, the present invention facilitates 
analysis of bid information. The present invention may utilize a separate analysis module 
to analyze the information received from a supplier. Embodiments within the scope of 
this invention may thus comprise means for analyzing information received from the 
suppliers. By way of example, and not limitation, in Figure 3 A such means for analyzing 
is illustrated by data cast analysis block 82. Data cast analysis block 82 may be any type 
of analysis module adapted for analyzing or comparing information received from the 
various suppliers. In one embodiment, data cast analysis module 82 is a spreadsheet 
program. Information received from the various suppliers may be placed into the 
spreadsheet program to allow analysis and comparison of the various bids received from 
the suppliers. For example, data cast message 68 may comprise a plurality of prompts 
that identify specific information items requested from a supplier. Each supplier should 
therefore respond with specific items corresponding to each prompt. Each prompt may 
therefore represent a row in a spreadsheet program and each information item received 
from each individual vendor may be placed in a column of the spreadsheet. This would 
allow a rapid comparison of the amounts for each particular information prompt. Using 
a spreadsheet also allows further analysis on the information received from various 
suppliers. For example, trade off analysis, or other types of analysis may be performed 
to make intelligent purchasing decisions. 

In order to summarize the bidding process using the embodiment illustrated in 
Figures 3A and 3B, reference is now made to the Table below: 
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ACTION 


PERFORMED BY 


Submit Company Classification, and 
Product Information 


Buyer and/or Suppliers 


Maintain Global Database/Update Local 
Database 


Service Provider/Buyer 
and/or Supplier 


crowse ouppner juaiaoase ana /\ssemDie 
Supplier List 


Buyer 


Create Data cast 
Object Using Supplier List and Other 
Information 


Buyer 


Send Data cast Message to Suppliers 


Buyer or Service 
Provider 


Send Reminders to Suppliers 


Buyer or Service 
Provider 


Respond to Data cast Message 


Suppliers 


Collect Supplier Responses 


Buyer or Service 
Provider 


Analyze Supplier Responses 


Buyer 



As indicated in the Table above, the first step is for a company to submit 
company, classification, and/or product information. This action is performed by buyers 
and/or suppliers. In Figure 3B, such information is submitted by suppliers 12 using 
database update message 52. Service provider 14 receives database update message 52, 
extracts the appropriate information and stores it into central database 24. The 
information may be transferred from central database 24 to local database 36 either 
through information request message 56 or through database update request 62. 

As indicated in the Table above, maintenance of the global database is handled 
by the service provider and update of the local database by transferring information to the 
local database is handled by a combination of the service provider and the buyer and/or 
supplier. . 

The bid process begins when a buyer browses the database and identifies a list of 
suppliers that should receive a request for bid. The buyer also creates a message and 
response tracking object such as data cast object 74, using the supplier list and other 
information such as the data cast message information previously described. The created 
data cast object comprises the data cast message that will be sent to the suppliers as well 
as a receiver object for each supplier on the supplier list. 
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Because the data cast object forms a unit of information that contains both 
broadcast and response information relating to a bid, the data cast object can serve as a 
magnet for responses and may be passed from individual to individual. For example, 
once the data cast object has been created the next step is to send the data cast message 
5 to the various suppliers. In the embodiment illustrated in Figures 3A and 3B such a 
process is accomplished by the buyer. In an alternative embodiment, this step may be 
performed by the service provider. In other words, a buyer may transfer a data cast object 
to the service provider and the service provider can be responsible for broadcasting 
messages and receiving responses from the various suppliers. 

1 0 Once the data cast message has been sent to the suppliers, it may be necessary to 

send reminders to the suppliers if they do not respond by one or more reminder dates. 
This step is illustrated in Figures 3 A and 3B by reminder message 80 sent to suppliers 12 
by supplier communication processing block 76. As in the case of the data cast message 
itself, such a function may also be performed by the service provider if the data cast 

1 5 object is transferred to the service provider and if responsibility for sending reminders is 
transferred to the service provider along with the data cast object. 

As responses are received from the various suppliers, the responses are collected 
and stored into the data cast object. As indicated in the Table above, this step may also 
be performed either by the buyer or the service provider. In the embodiment illustrated 

20 in Figure 3 A and 3B, supplier communication processing block 76 of the buyer performs 
this step. Alternatively, if a data cast object is transferred to service provider 14, the data 
cast object may serve as a magnet for the responses. As responses are received by the 
service provider, the responses may then be stored into the data cast object. 

After all appropriate information has been received and stored into the message 

25 and response tracking object, such as data cast object 74 of Figure 3 A, then the data cast 
message and response tracking object may be transferred to an individual, department, 
or other location for analysis of the bid. When performing an analysis of the responses, 
an analysis module, such as data cast analysis block 82 of Figure 3 A, may be used to 
display or analyze the data received. As summarized in the Table above, the analysis of 

30 supplier responses is typically performed by the buyer. However, since all information 
relating to a data cast is contained within a single object, the object may be stored or 
transferred internally to various departments for analysis. 

. Returning for a moment to Figures 3A and 3B, one final aspect of the 
embodiment illustrated therein is presented. Focusing for a moment on supplier 12, it is 

3 5 apparent that supplier 1 2 has a possibility of receiving data cast messages from a plurality 
of buyers. Thus, it would be desirable to allow supplier 12 to manage all of the data cast 
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information received from various buyers. In order to help achieve this function, 
supplier 12 may maintain a response database. In Figure 3B this response database is 
illustrated by response database 84. When a data cast message is received by supplier 
12, the data cast message and any response sent thereto may be stored in response 

5 database 84. Furthermore, client software on supplier 12 may allow easy management 
of the various data cast messages and responses. For example, client software on supplier 
12 may automatically remind supplier 12 of approaching deadlines. Because data cast 
message 68 contains deadline and reminder information, client software on supplier 12 
may docket these dates in an internal docket or calendaring system in order to 

10 automatically track deadlines as they approach. Furthermore, responses sent in response 
to data cast .message 68 may be stored in response database 84 in order to allow a supplier 
to track the bids that have been submitted. 

Turning now to Figure 4, the details of one implementation of local database 
maintenance processing block 60 of Figure 3 A are presented. As previously summarized 

15 above, local database processing block 60 is responsible for ensuring that local 
database 36 is properly updated. Thus, Figure 4 begins with decision block 86 which 
identifies whether the local database needs to be updated. As described in conjunction 
with Figure 2, local database 36 may be updated on a periodic basis so that local database 
maintenance processing block 60 sends a request to service provider 14 on a periodic or 

20 regular schedule in order to receive any new information. As an alternative, such an 
update may be performed manually. For example, a buyer may wish to manually update 
the database information before creating an important bid. As yet another alternative, 
anytime a buyer begins the bid creation process, local database processing block 60 may 
request an update to ensure that local database 36 is current. Alternatively, updates may 

25 be initiated by service provider 14. Such options have been previously described in 
conjunction with Figure 2 and any of such options will work in Figures 3A and 3B. 

If the local database is to be updated, then execution proceeds to step 88 which 
sends a request to service provider 14. Such a request may be local database update 
request message 62 or, as described in conjunction with Figure 2, may be an information 

30 request such as information request message 56. All that is necessary, is that service 
provider 14 be notified via an appropriate mechanism that an update to the local database 
is being requested. Execution then proceeds to step 90 which receives the updated 
information from service provider 14. Such update information may arrive in local 
database update information message 64 or database information message 58 as 

35 illustrated in Figures 3A and 3B. As information is received from service provider 14, 
step 92 indicates that the information in local database 36 should be updated. If multiple 
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messages are needed to update the local database, then information may be stored in the 
local database as each message is received. Alternatively, all messages may be stored and 
then the local database updated at one time. 

Referring next to Figure 5, the details of one implementation of data cast creation 

5 processing block 66 of Figure 3A is presented. As previously described, data cast 
creation processing block 66 may represent means for creating a message and response 
tracking object and means for accessing a database comprising information about 
suppliers and products. These functions are more specifically illustrated in Figure 5. 
In Figure 5, step 94 illustrates that the first function to be performed is to allow 

10 a user to browse the local database and to assemble a list of suppliers. This step thus 
represents one example of means for accessing a database comprising information about 
suppliers and products. As previously discussed, local database 36 preferably allows easy 
access to information stored in the database. For example, a user may access various 
classifications in order to identify all suppliers or products that fall in certain 

1 5 classifications. As another example, it may be desirable to allow key word searches on 
various data fields in local database 36. In essence, it is desirable to allow a user to 
browse information contained in local database 36 in an intuitive maimer in order to 
reduce the time it takes to locate suppliers that offer appropriate goods or services. As 
suppliers are located, the user should be able to add them to a distribution list. 

20 After the list of suppliers has been identified, step 96 indicates that the next action 

is to allow the user to enter data cast information and a message body. Such a function 
may be performed for example, by presenting the user with a form or template having 
various fields that can be filled out in order to create the appropriate information. Any 
of the fields previously described in conjunction with data cast message 68 of Figures 3 A 

25 and 3B may be presented to a user. Where automatic generation of an appropriate field 
is available, it may be preferable to present a default value in a field and allow a user to 
change the default value if desired. In addition, a database of past messages or data cast 
messages may be kept in order to allow a user to bring up a past message and copy one 
or more fields into the current data cast message. 

30 Proceeding now to step 98, after basic data cast information and message body 

have been created, the next step is to allow the user to enter data cast prompts. As 
previously explained, a data cast message may contain a series of prompts that will be 
displayed to a supplier and that identify particular pieces of information the buyer 
requires. If all that is necessary is a final price be submitted, then the user can enter a 

35 single prompt for the final amount of the bid. If, however, the buyer wishes greater 
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detail, then the buyer can enter a series of prompts that will be displayed and that identify 
information that should be returned by the supplier. 

The series of prompts provides a convenient point of comparison for the various 
bids. For example, as previously explained in conjunction with data cast analysis 
5 module 82, and as presented in Figure 7 below, it may be desirable to place each prompt 
in a row of a spreadsheet program and place the various responses received from various 
suppliers in columns. Thus, the prompts provide a convenient point of comparison for 
the various bids and may be use in various ways to analyze and compare the bids. 

As indicated in Figure 5, the next step is to create the data cast message. This is 
1 0 indicated in Figure 5 by step 100. After a user has entered or retrieved the information 
required by steps 94, 96, and 98, all information necessary for a data cast message should 
be available. Thus, data cast message 68 may be created at step 100. 

After the data cast message has been created, step 102 indicates that receiver 
objects are created. As previously described, a response tracking or receiver object is 
1 5 created for each of the suppliers on the supplier list. This ensures that when a response 
is received from a particular supplier that appropriate space has been allocated and exists 
to store the information received in the response. 

After the receiver objects are created, step 104 then assembles the data cast 
message and the receiver objects into a single data cast object. As previously explained, 
20 such a data cast object represents but one example of a message and response tracking 
object that forms a contained unit of information that is used throughout the present 
invention. Step 1 04 is an example of means for creating a message and response tracking 
object. 

Referring now to Figure 6, one implementation of supplier communication 
25 processing block 76 of Figure 3A is presented. As explained above, supplier 
communication processing block 76 is responsible for all communications between the 
suppliers and the buyer. Although the embodiment illustrated in Figures 3 A and 3B 
indicates that this function is performed by the buyer, in alternative embodiments, the 
data cast object may be passed to the service provider and the service provider would 
30 perform analogous functions. 

In communicating with the suppliers, supplier communication processing block 
must be able to handle three specific events. The first event is that a response has been 
received from a particular supplier. The second event is that a reminder message should 
be sent to one or more suppliers. The final event is that a data cast message should be 
35 broadcast to a list of suppliers. In Figure 6, these three events correspond to decision 
blocks 106, 108, and 110. Referring first to decision block 106, supplier communication 



WO 01/16826 PCT/US00/18943 

32 

processing block 76 tests whether a response has been received. If such a response has 
been received, then execution proceeds to step 112 where appropriate information is 
extracted from the response and placed into the corresponding receiver object in the data 
cast object. Any of the information previously described in conjunction with Figures 3A 
5 and 3B may be stored into the receiver object. The key point is that placing such 
information into the receiver objects allows data cast object 74 to become a contained 
unit of information that can be operated upon. After step 112, execution proceeds back 
to the start to await the next event. 

Examining decision block 1 08, supplier communication processing block 76 tests 

10 whether a reminder message should be sent. As previously explained, when a data cast 
object is created a user may enter milestone or reminder dates that will trigger events in 
the system. For example, a reminder date will trigger a reminder message to be sent to 
those suppliers that have not responded by the reminder date. In certain embodiments it 
may be desirable to allow a plurality of reminder dates to be entered. In other 

1 5 embodiments, a single reminder date may be sufficient. 

When a reminder is to be sent, execution proceeds to step 1 14 which creates the 
reminder message and sends a copy to the suppliers that have not yet responded. Such 
a reminder message may be a simple text message that reminds a supplier that they have 
not yet responded or may be more complex containing various information up to, and 

20 including, all information in original data cast message 68. 

Referring next to decision block 110, supplier communication processing 
block 76 tests whether a data cast message should be sent. Strictly speaking, such a 
decision block may not be necessary if only three events are sent to supplier 
communication processing block 76. If supplier communication processing block 76 

25 only receives notification of the three events identified in decision blocks 1 06, 1 08, and 
110, then decision block 110 may be safely eliminated since by default if execution 
proceeds through decision block 106 and decision block 108 the only remaining event is 
that a data cast message should be sent. 

If a data cast message should be sent, execution proceeds to step 116 where the 

30 data cast message is extracted from the data cast object. As previously described, a 
message and response tracking object, such as data cast object 74, may comprise the data 
cast message that is to be sent to the various suppliers. Step 116 extracts this message. 
Execution then proceeds to step 118 where the data cast message is broadcast to the 
designated suppliers. Execution then proceeds back to the start to await the occurrence 

35 of the next event. 
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Turning next to Figure 7, one implementation of data cast analysis block 82 of 
Figure 3 A is presented. As previously explained, the present invention is ideally suited 
to using separate analysis modules to display or analyze the responses received from the 
various suppliers. This is because all information is collected into a central repository 
that can be ^passed from location to location and individual to individual. Thus, the data 
cast object may be passed to an analysis module for further analysis and display of the 
various information received from suppliers. In Figure 7, step 120 indicates that the first 
step of the analysis module is to extract response information from the data cast object. 
As previously explained in conjunction with the response object 72 used in data cast 
object 74, information may be stored that identifies what information should be extracted 
from the response and placed into an analysis module. For example, company 
information may be extracted and displayed as a header over a company's bid. In 
addition, the information returned in response to the various prompts sent in the data cast 
message may be extracted and displayed in a spreadsheet or other analysis module. Thus, 
step 120 extracts the appropriate information and formats it for use by the analysis 
module. 

After the appropriate information has been extracted, step 122 transfers or places 
the response information into the analysis module. Such a process may require 
information to be transferred to the analysis module or that a handle or link to the 
information be passed to the analysis module so that the analysis module may be able to 
extract or reference the appropriate information. 

Step 124 indicates that after the information has been placed into the analysis 
module, then the analysis module should display the response information and allow the 
user to analyze the data. The goal of this step is to allow a user to display or analyze 
information in appropriate ways in order to make sound purchasing decisions. If such 
analysis requires a plurality of analysis modules or a suite of analysis tools, then the 
process of the present invention can be adapted to accommodate such a suite. In one 
embodiment of the present invention, the information is transferred into a spreadsheet 
program, such as Microsoft® Excel. When Excel or another windows compliant 
spreadsheet program is utilized, the present invention may use the various functionality 
provided by the spreadsheet program to transfer information from data cast object 74 to 
the spreadsheet program. For example, Microsoft has defined a standard called OLE that 
allows information from one program to be linked and embedded into another program. 
Thus, information from data cast object 74 may be linked or embedded into a spreadsheet 
program using this technology. Other methods may exist on other computers to allow a 
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similar propess to be performed. If appropriate analysis tools do not exist, then such 
analysis tools may be created and made part of the present invention. 

Although embodiments of the present invention have described the use of a single 
message and response tracking object, such as data cast object 74 of Figure 3A, as a 
5 central repository for all information relating to a bid, other equivalent methods to the use 
of such an object are available. For example, a folder may be created where all 
information received is placed. This folder can then become the repository of 
information and can act like a single message and response tracking object. All that is 
required for the present invention is a single location or repository for all information 

1 0 regarding a particular data cast that can be transferred and that can serve as a magnet for 
communications received from the various suppliers. 

In referring to Figure 8, a flow diagram illustrating one implementation of the 
electronic community (e.COMMUNITY) is illustrated. Decision block 126 identifies 
whether a new member of the e.COMMUNITY needs to be created. Normally, 

15 membership to the larger e.COMMUNITY will be granted to individuals without 
imposing limitations. However, the service provider does maintain the ability to regulate 
access to the general electronic community. While Figure 8 demonstrates three unique 
features possible within the e.COMMUNITY, they should not be viewed as necessary 
limitations on the embodiment rather as independent implementations. These functions 

20 are: the creation of member records; the creation of commerce subgroups; and general 
commerce activities. 

Processing block 128 collects new member information including location of 
business, contact information, and basic product information to be stored on the central 
database for the general community. Buyers can provide their company profile and 

25 contact information. Suppliers can modify any and all aspects of their profiles, contact 
information; manufacturers, products, and classifications at any time, to ensure that the 
information presented to the buyers is correct and up-to-date. Managers may even choose 
which suppliers can be viewed and selected for bids by the buyers under them. Once the 
desired information has been collected, execution block 130 submits this information for 

30 inclusion within the central database of the e.COMMUNITY. Processing block 132 
establishes the new member's membership within the e.COMMUNITY providing the 
individual with access keys and codes to allow it the ability to make general 
e.COMMUNITY solicitations, to participate in private marketplaces, and to create new 
marketplaces. Once membership has been established, the data flow branch returns the 

35 new member to the home state 134 of general e.COMMUNITY activities. If decision 
block 126 returns a negative response for the creation of a new member, the data flow 



WO 01/16826 



PCTAJS00/18943 



35 

branch allows an existing member to login and leads the member directly to the home 
state 1 34 for general e.COMMUNITY activities. An update feature similar to the new 
member-creation branch exists for members to update their information in the central 
database. According to this update feature a member, a service provider, or an 
e.COMMUNITY administrator may update information within the member object for 
access by other members within the community. From the home state 134, the members 
of the e.COMMUNITY may choose to make solicitations or requests for bid to the 
general e.COMMUNITY, to respond to solicitations, to create new marketplaces, and 
to participate in various other community commerce transactions. 

Another important feature of this e.COMMUNITY model is the ability of a 
member to create a new electronic marketplace. The preferred method used by members 
is to utilize "on the fly" or "on demand" marketplace creation techniques. "On demand" 
marketplace creation is when the marketplace administrator is allowed to create an 
electronic marketplace containing suppliers and purchasers with common categorical 
features. These features include locality, industry, product, or service category. Thereby 
allowing suppliers and purchasers to join or create electronic commerce groups where all 
of the products offered in the marketplace are of interest to the purchaser at the time the 
marketplace is created. Thus, resources expended towards pursuing a request for bid from 
a specialty marketplace, formed by the participants "on demand," are often more cost 
effective than spending corporate resources on general advertising, sales force 
development, or other client development campaigns. Instead, many of these overhead 
costs can be reduced or eliminated maximizing the overall effectiveness of the bid. 
Should a member of the general e.COMMUNITY desire to create such a specialty 
marketplace, they would move to processing block 136 create new marketplace. Within 
this marketplace, a series of prompts establish the individual member as an administrator 
to the marketplace. 

Once the new administrator is established Processing block 138 presents a series 
of prompts allowing the administrator to establish various marketplace parameters, 
including but not limited to, the transactional costs imposed upon suppliers and/or 
purchasers, price change regulation, the size of the marketplace, the product or category 
focus of the marketplace, pricing groups, regions served, proxy suppliers, and the 
membership or individual cost of participation within the marketplace. Both Buyers and 
Suppliers may be charged for the privilege of joining a marketplace. This charge may be 
either a flat fee, for example $100, or a transaction fee, such as 2% of wholesale price of 
goods sold via the system. As might be expected, the marketplace administrator can also 
decide that joining the marketplace will be free to buyers and/or suppliers. If the 
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marketplace administrator decides to regulate price changes, all price changes made by 
suppliers participating in the market must be approved or made by the marketplace 
administrator. This feature can protect the buyers and suppliers by allowing the 
marketplace administrator to notify interested parties of certain price changes. This 
control feature also allows the marketplace administrator to provide third party 
certification concerning product pricing at the time the purchase transaction is closed. 
Another marketplace parameter regulated by the administrator is the size of a 
marketplace. The administrator may limit the number of buyers or the number of 
suppliers participating in the marketplace. One method of size regulation is through 
advertising on a general electronic community list which contains all the marketplaces 
that are open to new enrollment of suppliers or buyers. Suppliers wishing to join a 
marketplace created by someone else can view and apply for membership from a list of 
all available marketplaces. Suppliers and Buyers may also remove themselves from 
membership in a specific marketplace, potentially causing the released marketplace to be 
added to the available list. The marketplace administrator may also allow prospective 
member buyers or suppliers to view a list of suppliers and their products already in the 
marketplace. A further control available to the marketplace administrator is the ability 
to set the categories of products within the marketplace, to determine the price offered 
to buyers from the suppliers in the marketplace. Pricing groups can be established for 
each product category. Pricing groups are assigned a base price for each product and the 
price seen by a buyer for a product is based on a margin percentage or override value. 

An additional control given to a marketplace administrator is the ability to proxy 
suppliers; namely, the marketplace administrator will appear to the buyers in the 
marketplace as the source of the product objects. When in actuality, the product objects 
are owned and maintained by another supplier who has contracted with the marketplace 
administrator to distribute their product. Purchase orders received by the marketplace 
administrator are then electronically routed to the suppliers who own the products being 
purchased 'and the products are either sent to the marketplace administrator for further 
distribution to the buyer or sent directly to the buyer from the actual supplier. The 
marketplace administrator is also given the ability to group the suppliers into a 
marketplace by region and allow the buyers in the marketplace the option to select only 
those suppliers in a marketplace from own region. Some marketplace administrators may 
find it useful to give selected responsibilities over a specific category or function (e.g., 
membership, pricing, or regional coordination) to another administrator. This category 
administrator can make and regulate changes to a supplier's products within the category 
and establish pricing groups of buyers for the category just like the marketplace 
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administrator. This feature is useful when the marketplace grows too large for a single 
marketplace administrator to effectively handle all of the product categories. The 
marketplace administrator can determine the extent of authority that the category 
administrator is granted within various product categories. 
5 Additional marketplace parameters include whether the new marketplace will be 

offered to buyers based on regions as a local Public Marketplace or will the buyers be 
"hand-picked" creating a more Private Marketplace. A Public Marketplace is a 
marketplace where many suppliers make their products available to all companies in a 
specified region. A Private marketplace is a marketplace where many suppliers make 

1 0 their products available to specific Buyers. Once these variables have been established, 
selection block 140 allows the new administrator to select the invitees from the central 
database 16 of e.COMMUNITY members for the new marketplace. This selection may 
be done in a variety of ways, either by addressing the specific invitees or by compiling 
a group of individuals who sell a specific product category or product with purchasers 

1 5 interested in these products. Once these individuals have been selected, execution block 
142 sends invitations to each of the members of the e.COMMUNITY previously selected 
by the administrator inviting them to join the new marketplace. 

Decision block 144 determines whether the individuals have accepted or rejected 
the invitation to join the marketplace. Should the invitation return a negative response, 

20 the notification block 146 alerts the marketplace administrator of the decision by an 
individuaf invitee not to join the marketplace. Decision block 148 then allows the 
marketplace administrator the opportunity to add or select a replacement to the 
marketplace for the individual who declined the invitation to join. If the administrator 
decides to choose a replacement, the marketplace administrator returns to processing 

25 block 140 and is allowed to select additional invitees from the central database 1 6. While 
a central database 16 is used in Figure 8, a local database, categorical database, or 
dispersed database could be used. 

Should decision block 144 indicate that the individual accepted the invitation, 
processing block 150 adds the individual member to the marketplace. This is 

30 accomplished in part by attaching a supplier's products to the marketplace object and 
attaching the purchaser's contact information within the reach of the suppliers through the 
marketplace object. Once the individual has been added to the marketplace, decision 
block 152- checks to establish whether the marketplace has a sufficient number of 
participants to open for purchasing transactions. Factors which prevent the marketplace 

35 from opening can include only having suppliers or vendors respond to the initial 
invitation, or not satisfying the minimum number of marketplace participants. If the 
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marketplace status does not satisfy the underlying marketplace parameters, the 
notification block 146 will alert the marketplace administrator to the potential need to add 
or select additional participants for membership within the marketplace. If the 
underlying parameters previously established for the market are satisfied, the decision 
block 152 will return a positive response and move to the execution block 154 opening 
the marketplace for general commerce to all members within the marketplace. This 
action does not prevent additional members from accepting invitations and joining the 
marketplace later, it merely allows those who respond early to begin trading. The 
administrator following notification block 146 may decide an adjustment of the 
markplace parameters is necessary. Once these changes to the marketplace parameters 
are made, the administrator may open the marketplace by moving to the execution block 
1 54. Another method of commerce available to members of the e.COMMUNITY is 
the ability to make general e.COMMUNITY solicitations. Processing block 1 56 collects 
the information from the individual desiring to make such a solicitation including details 
about the product being offered or the request for bid being made. Processing block 158 
collects the information and creates a data cast module similar to those previously 
mentioned. Execution block 160 filters solicitation based on the member settings which 
establish the types of contact desired by each e.COMMUNITY member, thereby 
eliminating junk solicitation not conducive to business. Execution block 160 is an 
optional block in the preferred embodiment as some suppliers and vendors may prefer an 
open format to the filtered environment offered by this embodiment. The remainder of 
the processconforms with the previous data cast discussion. 

Processing block 162 creates a message object containing the information to be 
included within the data cast and to be sent to each of the recipients of the solicitation. 
Processing block 164 creates the receiver objects including the responses to the message 
object from each of the individuals responding to the solicitation. Execution block 166 
assembles the message and receiver objects into the data cast object. Processing block 
1 68 transmits this data cast object back to the original solicitor. Then execution block 1 70 
extracts the information from the data cast object to display all of the response 
information. Execution block 172 allows the user to complete the transaction either by 
making a purchase or by allowing the request for bid to expire without a successful 
solicitation. 

Figure 9, illustrates an electronic community 174 where a plurality of buyers and 
suppliers may conduct purchasing transactions. Figure 9 is also a top level diagram of 
an electronic marketplace 176 using a flexible repository that is not entirely dependent 
upon a central database 16. The preferred embodiment calls for a marketplace 
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administrator 178 to select the participants for the electronic marketplace 176 from a 
central database 16 containing all of the suppliers and buyers participating in the 
electronic commerce community. Alternative embodiments do not require using a central 
database, for example, the suppliers and buyers may be asked to create their information 
5 for each electronic marketplace 176 when they accept membership. Other embodiments 
allow a local database containing all of the local suppliers and buyers to be substituted 
for the central database 1 6 of the service provider. An additional substitute for the central 
database 16 includes a categorical database, containing all of the members of the 
electronic community 174 who have listed a particular category of products, as one that 

10 they desire to participate in. Another substitute is a dispersed database containing 
suppliers and vendors approved by a purchasing supervisor, manager, or administrator. 
In this manner, the dispersed database regulates which suppliers a company's purchasing 
agents may contact. The marketplace administrator 178 creates the marketplace, 
designates the properties within the marketplace, creates all of the marketplace 

1 5 categories, selects which suppliers may join, and chooses the buyers that may access and 
subscribe to the marketplace. The suppliers represent vendors, retailers, wholesalers, and 
manufacturers that the marketplace administrator has invited to join in the marketplace. 
They are allowed to post their products in the marketplace categories. Buyers represent 
purchasers, procurement groups, and consumers selected by the marketplace 

20 administrator to subscribe to the marketplace for the purpose of bidding and buying from 
these suppliers. The marketplace administrator may also function as either a supplier or 
buyer within the marketplace. Furthermore, participants in the marketplace may have 
multifaceted roles that include both buyer and supplier functions. Once the selection has 
been made the electronic marketplace 176 sends invitations to selected buyers and 

25 suppliers. It also creates a marketplace object 1 80 to maintain information about all the 
participants in the electronic marketplace. 

The electronic marketplace 176 may be created by a marketplace administrator 
178 for one enterprise or for multiple commercial groups. Access and transactional fees 
to the electronic marketplace 176 are controlled by the marketplace administrator 178 for 

30 the enterprise. The marketplace administrator 1 78 may also act as a proxy supplier for 
the electronic marketplace 176 so that the buyers see the marketplace administrator 178 
as the supplier rather than the actual drop-ship supplier. In some embodiments of the 
present invention, there is no central database 16 for use by the localized marketplace. 
In such a system a marketplace object 1 80 will contain all of the product information and 

35 participant information. This allows the marketplace object 1 80 to be passed between the 
marketplace participants like a file folder containing all of the relevant information. 
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Additional features included within the preferred embodiment of the electronic 
marketplace include: a means for Purchase Order tracing to allow the buyer to check the 
complete history and the current status of a Purchase Order; and means for Split Purchase 
Order issuance, allowing multiple suppliers to be issued a purchase order from one buyer 
5 purchase order. This allows the buyer to shop within an electronic marketplace and only 
make one purchase order, and the electronic marketplace 176 divides up the order and 
notifies the suppliers. This feature is particularly useful when the marketplace 
administrator has established themselves as a proxy supplier. In effect, the buyer only 
needs to pay the proxy supplier and the proxy supplier will pay the suppliers. 

1 0 Additionally, the marketplace administrator 1 78 may place an enterprise name in the Tool 
Bar thereby allowing the proxy supplier to personalize the marketplace, in effect creating 
a virtual store full of various suppliers for the buyer to purchase from. Within the 
marketplace object 180, products available within the marketplace are classified using 
Tab-strip classifications to increase the product search options available to the buyer. 

15 Another feature of the preferred embodiment is an Ignore utility that allows buyers to 
select other marketplace members to ignore. This feature allows members to protect 
themselves from unnecessary junk mail concerning products in which they have no 
interest. The ignore feature also allows a member to avoid doing business with other 
members who may have not satisfied expectations in previous business dealings. One 

20 feature useful in an age where businesses are often required to demonstrate compliance 
with various minority certification standards is an improved Minority Certification 
feature. This feature allows marketplace vendors to use and provide Minority 
Certification for certain projects. 

Referring to Figure 9, Supplier 182 represents a supplier within the electronic 

25 community 174 who is not invited to join the electronic marketplace. Supplier 184 
represents a vendor who is invited to join but decides not to join the marketplace. 
Supplier 186 represents a supplier who is invited to join but chooses only to attach some 
of the supplier's products for display with the marketplace object. Supplier 188 
represents a supplier who is invited to join the marketplace and attaches all of his 

30 products to the marketplace object. Supplier 190 represents an individual operating as 
both a vendor and buyer within the marketplace. This characteristic enables the 
individual to both view and add product objects to the marketplace object. Buyer 192 
represents a buyer within the electronic community 1 74 who is not extended an invitation 
to join the electronic marketplace. Buyer 194 represents a buyer who is invited but does 

3 5 not join the* marketplace. Buyer 1 96 represents a buyer who joins the marketplace and 
makes a purchase from supplier 200. Buyer 198 represents a buyer who joins the 
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marketplace after receiving an invitation and makes a request for bid but makes no further 
transaction. The marketplace administrator 178 can be either a buyer, vendor, or a 
separate entity charged with regulating the operation of the electronic marketplace 176. 
All of the aforementioned suppliers and buyers are members of an electronic community 
1 74 of subscribers to a larger marketplace. The marketplace administrator 178 does not 
need to be a member of the electronic community 174, however; the most common type 
of marketplace administrator 178 is a member of the electronic community 174 
instigating the creation of the smaller private electronic marketplace 176. The electronic 
marketplace 176 represents a separate private marketplace from the larger electronic 
community 174. The electronic marketplace 176 contains a marketplace object 180 
which may be viewed by the vendors and suppliers who have accepted invitations to join 
the marketplace 176. The electronic marketplace 176 is given responsibility to maintain 
the purchasing standards established by the marketplace administrator 178 and to send 
the necessary invitations to the suppliers, vendors, and buyers within the electronic 
community 174. 

The present invention may be embodied in other specific forms without departing 
from its spirit or essential characteristics. The described embodiments are to be 
considered in all respects only as illustrated and not restrictive. The scope of the 
invention is, therefore, indicated by the appended claims rather than by the foregoing 
description. All changes which come within the meaning and range of equivalency of the 
claims are to be embraced within their scope. 
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What is claimed is: 

1 . A method for offering membership to organized private marketplaces from 
general subscribers of electronic commerce users and for creating membership in said 
marketplace to at least one buyer and at least one supplier, the method comprising the 
steps of: 

creating a marketplace object comprising a group of suppliers and a group 
of buyers who a marketplace administrator invites to join the organized private 
marketplace; 

sending said marketplace object to those suppliers and buyers that were 
invited to join said organized private marketplace; 

receiving from said at least one supplier and at least one buyer an 
acceptance to the said marketplace object invitation to join the marketplace; 

attaching product objects from said at least one supplier who chose to join 
the marketplace to said marketplace object such that said marketplace object is 
attached to product objects from all participating suppliers; and 

viewing said product objects attached to the marketplace object by said 
at least one buyer who chose to join the marketplace. 

2. A method for offering membership and for creating membership as recited 
in claim 1, further comprising the step of selecting products to purchase and creating 
multiple purchase orders automatically from said at least one buyer who chose to join the 
marketplace to each unique said supplier who chose to join the marketplace. 

3. A method for offering and for creating marketplace membership as 
recited in claim 1 further comprising the step of allowing the marketplace administrator 
the ability change the price properties of the product objects within the marketplace 
object. 

4. A method for offering and for creating marketplace membership as recited 
in claim 1 wherein the product objects include special pricing objects, said pricing objects 
comprising tiered pricing, percentage discounts, and industry standard pricing policies. 

5 . A method for offering and for creating marketplace membership as recited 
in claim 1, wherein the marketplace administrator may also be included in the group of 
buyers, the group of suppliers, or act as an independent third party, said group of buyers 
and group of suppliers being selected from a larger grpup of electronic commerce users. 

6. A method for offering and for creating marketplace membership as recited 
in claim 1 further comprising the step of updating said marketplace object and sending 
said updated marketplace object to said at least one supplier and to said at least one buyer 
so that said updated marketplace object supersedes and replaces said marketplace object. 
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7. A method for offering and for creating marketplace membership as 
recited in claim 1 further comprising the step of transferring said product objects to an 
analysis module where said product objects can be compared and analyzed. 

8. A method for offering and for creating membership as recited in claim 1 
5 further comprising the step of sending reminders for bids, responses to bids, or 

membership invitations to said at least one buyer or supplier if a response is not received 
from said at least one buyer or supplier by a predefined date. 

9. A method for offering and for creating membership as recited in claim 1 
further comprising the step of creating pricing-group objects to which a number of buyers 

10 in the marketplace are assigned to determine the price offered to those buyers from the 
suppliers in the marketplace. 

10. A method for offering and for creating membership as recited in claim 1 
further comprising the step of allowing a marketplace administrator to proxy suppliers; 
namely, the marketplace administrator appears to the buyer in the marketplace to be the 

15 source of the product objects but in actuality, the product objects are owned and 
maintained by another supplier who has contracted with the marketplace administrator 
to distribute the supplier's product objects; and forward purchase orders received by the 
marketplace administrator to the suppliers who own the products being purchased. 

11. A method for offering membership and for creating membership as recited 
20 in claim 1 wherein said marketplace object groups the suppliers into a marketplace by 

regions or geographic location, thereby allowing the buyers in the marketplace the option 
to select only those suppliers in a marketplace from their region. 

12. - In a computer communications system, a method of creating an electronic 
marketplace between at least one buyer and at least one supplier to automate supply chain 

25 communication, enhance competitive bidding, and provide for effective completion of 
a purchase transaction through electronic purchase orders, the steps of said method 
comprising: 

creating a electronic marketplace environment comprising a marketplace 
object, said marketplace object comprising an initial list of suppliers and an initial 
30 list of buyers selected from a larger list of electronic commerce users; 

inviting members of said initial list of suppliers and said initial list of 
buyers to join said electronic marketplace environment by providing said 
electronic commerce user on either of said initial lists with the marketplace object 
from said electronic marketplace environment; 
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attaching product objects of said at least one supplier to the marketplace 
object, if that supplier accepts the invitation to join the electronic marketplace 
environment, said product object including special pricing objects; 

modifying the product objects and special pricing objects according to 
variable guidelines provided by said at least one supplier; 

providing product objects for viewing to said at least one buyer if that 
buyer accepts the invitation to join the electronic marketplace environment; 

allowing said at least one buyer who joins the marketplace to select 
products from the electronic marketplace environment to purchase; 

creating a purchase order for said at least one supplier containing products 
selected from that supplier by said at least one buyer; and 

tracing the delivery of said products from said at least one supplier to said 
at least one buyer. 

13. A method of creating an electronic marketplace as recited in claim 12 
further comprising the step of consulting a database containing product information and 
selecting said at least one supplier from said database for said initial list of suppliers 
based on said product information. 

14. A method of creating an electronic marketplace as recited in claim 12 
further comprising the step of extracting information from said product and special 
pricing objects and transferring said extracted information to an analysis module where 
said extracted information can be compared and analyzed. 

15. A method of creating an electronic marketplace as recited in claim 12 
further comprising the step of sending a reminder to said invited members if a response 
is not received from at least one invited supplier or at least one invited buyer by a 
predefined date. 

16. A method of creating an electronic marketplace as recited in claim 12 
wherein said marketplace object includes a product query object comprising a sequence 
of prompts entered by said buyer, said prompts being displayed to said at least one 
supplier when said product query object is received and examined by said at least one 
supplier, said prompts comprising one prompt for each item of information that said 
buyer wishes to receive. 

17. A method of creating an electronic marketplace as recited in claim 16 
wherein said product query tracking object comprises the date that a reminder should be 
sent to said at least one supplier if a response is not received from said at least one 
supplier. 
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18. A method of creating an electronic marketplace as recited in claim 17 
wherein said product query object comprises the date that a response is due from said at 
least one supplier if said response is to be considered by said buyer. 

19. A method of creating an electronic marketplace as recited in claim 18 
wherein said product query comprises attached documents in addition to any message 
text. 

20. A method of automating purchase transactions utilizing an electronic 
commerce communication system with multiple user-defined submarketplaces and 
controlled pricing capabilities, said method comprising the steps of: 

establishing a submarketplace of at least one buyer and at least one 
supplier, said submarketplace containing controlled pricing capabilities as 
dictated by a trading partner; 

exchanging product and pricing information between said buyer and 
supplier: 

upon agreement of said buyer and supplier, exchanging purchasing 
information between buyer and supplier; 

upon purchase approval, verifying that desired product is sent from 
supplier to buyer. 

21. A method of automating purchase transactions as in claim 20, wherein 
said at least one supplier is selected by the trading partner from a supplier database of 
general subscribers to said electronic commerce communication system. 

22. A method of automating purchase transactions as in claim 21 , wherein 
said selection of at least one supplier is made by the trading partner according to product 
pricing information extracted from said supplier database. 

23. A method of automating purchase transactions as in claim 22, wherein 
said at least one buyer is selected by the trading partner from a buyer database of general 
subscribers to said electronic commerce communication system. 

24. A method of automating purchase transactions as in claim 23, wherein 
said selection of at least one buyer is made by the trading partner according to product 
requests for bid information extracted from said buyer database. 

25. A method of automating purchase transactions as in claim 24, wherein 
said controlled pricing capabilities include establishing association costs and individual 
transaction fees within said submarketplace. 
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26. A method of automating purchase transactions as in claim 25, wherein 
said trading partner may require a flat fee, a graduated fee, or a transactional fee from the 
supplier for any successfully completed purchasing transaction. 

27. ^ A method of automating purchase transactions as in claim 25, wherein 
5 said trading partner may require a flat admission fee, a graduated quantity purchasing fee, 

or a transactional fee from buyers participating in a successful purchasing transaction. 

28. A method of automating purchase transactions as in claim 25, wherein 
said purchasing information exchanged between buyer and supplier include at least one 
electronic purchase order form, multiple electronic purchase order forms may be created 

10 and distributed to multiple suppliers from a single marketplace purchase order form as 
dictated by said at least one buyer's purchase selections, said multiple electronic purchase 
order forms indicating only the information corresponding to the purchase transaction 
between the buyer and the recipient of said at least one electronic purchase order form. 

29. A computer-readable medium having computer-executable instructions 
15 comprising: 

means for creating a marketplace object; 

means for creating a marketplace membership object comprising an 
enlistment message that is to be sent to at least one receiver and at least one 
response tracking object adapted for storing information received in response to 
20 said enlistment message; 

means for sending said enlistment message to at least one receiver and for 
receiving from said at least one receiver at least one response to said enlistment 
message; and 

means for storing information from said at least one response into said at 
25 least one response tracking object such that said message and response tracking 

object forms an integrated data unit that contains both the enlistment message and 
information from responses to said enlistment message. 

30. A computer-readable medium as recited in claim 29 wherein the 
executable instructions further comprising: 

30 means for accessing a database comprising information about said at least 

one receiver and about products offered for sale by said at least one receiver; 

means for analyzing information received from said at least one response 
and stored in said at least one response tracking object. 

31. A computer-readable medium as recited in claim 29 wherein the 
3 5 executable, instructions further comprising : 
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means for attaching product objects from said at least one receiver to said 
marketplace object when the response to the enlistment message is affirmative; 

means for viewing said product objects attached to the marketplace object; 

means for selecting said product objects attached to the marketplace 
object for creation of an electronic purchase order. 

32. A computer-readable medium having a plurality of data fields stored on 
the medium and representing a electronic marketplace data structure, comprising: 

a first data field representing a enlistment message that is to be sent to at 
least one receiver, said first data field being stored in a range of addresses in said 
computer-readable medium; 

one response object for each receiver that will receive said enlistment 
message, each of said response objects being stored in a separate range of 
addresses in said computer-readable medium, each of said response objects 
comprising: 

a data field adapted for storing a text response received from one of said 
receivers that receive said enlistment object. 

33. A computer readable medium as recited in claim 32 further comprising 
a date field adapted for storing the date that said enlistment message was sent to said at 
least one receiver. 

34. A computer readable medium as recited in claim 32 further comprising 
a date field adapted for storing the date that a reminder message should be sent to said at 
least one receiver. 

35. A computer readable medium as recited in claim 32 further comprising 
a date field adapted for storing the data that a response is due from said at least one 
receiver. 

36. A computer readable medium as recited in claim 32 further comprising 
a product field adapted for storing a plurality of data prompts that are received from said 
at least one receiver when said at least one receiver accepts said enlistment message. 

37. A computer readable medium as recited in claim 36 further comprising: 
. a bid field adapted for displaying said plurality of data prompts within 

said product field to said at least one receiver; 

at least one field identifying information needed by an analysis module to 
extract information from said product field adapted for storing a text response 
received from one of said receivers so that the extracted information can be 
analyzed by a user using said analysis module; 
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a purchase order field adapted for creating a purchase order from the 
plurality of data prompts generated by the analysis module. 
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